CC
Mark Burton (@markfoodyburton)
Brian Cain (@androm3da)
mahmdkamel

(For some reason, I'm not allowed to ask for reviews)

a gs::loader loads its image at end_of_elaboration, and that access can be routed by the router to a bridge that hasn't been initialized yet. b_transport then dereferences the null m_inst and segfaults.

But does that indicate some kind of misconfiguration that we shouldn't try to support?

Or just some configuration that we should support that none of the tests expose?

Mark Burton (@markfoodyburton) ?

a gs::loader loads its image at end_of_elaboration, and that access can be routed by the router to a bridge that hasn't been initialized yet. b_transport then dereferences the null m_inst and segfaults.

But does that indicate some kind of misconfiguration that we shouldn't try to support?

Or just some configuration that we should support that none of the tests expose?

Mark Burton (Mark Burton (@markfoodyburton)) ?

I agree, this is very strange - why is (e.g. the loader) trying to load to a qemu target like this?
I also agree it seems odd that it's so "late" to do the bind, I can't remember why that is, but I seem to remember there isn't much we can do about that.
Where I very much differ with the patch is that, IF somebody is trying to load to a qemu device before initialisation, then, simply ignoring it is probably very bad. At the least I would expect to return with an error, ideally generate a warning, possibly stop the simulation.

a gs::loader loads its image at end_of_elaboration, and that access can be routed by the router to a bridge that hasn't been initialized yet. b_transport then dereferences the null m_inst and segfaults.

But does that indicate some kind of misconfiguration that we shouldn't try to support?
Or just some configuration that we should support that none of the tests expose?
Mark Burton (Mark Burton (Mark Burton (@markfoodyburton))) ?

I agree, this is very strange - why is (e.g. the loader) trying to load to a qemu target like this? I also agree it seems odd that it's so "late" to do the bind, I can't remember why that is, but I seem to remember there isn't much we can do about that. Where I very much differ with the patch is that, IF somebody is trying to load to a qemu device before initialisation, then, simply ignoring it is probably very bad. At the least I would expect to return with an error, ideally generate a warning, possibly stop the simulation.

I agree on that, when we load to a qemu device very early, most of time this means we have an issue in the configurations of one or more target sockets, so I would prefer to SCP_FATAL with a meaningful message in this case instead of silently return a TLM OK response.

[...]
I agree on that, when we load to a qemu device very early, most of time this means we have an issue in the configurations of one or more target sockets, so I would prefer to SCP_FATAL with a meaningful message in this case instead of silently return a TLM OK response.

Indeed, rethinking this, a silent ignore doesn't seem like the best option. I'll close the MR for now (the issue I was seeing was already resolved with another PR)